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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 
Abstract 


The IP Security Authentication Header (AH) and Encapsulating Security 
Payload (ESP) protocols use a sequence number to detect replay. This 
document describes extensions to the Internet IP Security Domain of 
Interpretation (DOI) for the Internet Security Association and Key 
Management Protocol (ISAKMP). These extensions support negotiation 
of the use of traditional 32-bit sequence numbers or extended (64- 
bit) sequence numbers (ESNs) for a particular AH or ESP security 
association. 
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1. Introduction 


The specifications for the IP Authentication Header (AH) [AH] and the 
IP Encapsulating Security Payload (ESP) [ESP] describe an option for 
use of extended (64-bit) sequence numbers. This option permits 
transmission of very large volumes of data at high speeds over an 
IPsec Security Association, without rekeying to avoid sequence number 
space exhaustion. This document describes the additions to the IPsec 
DOI for ISAKMP [DOI] that are needed to support negotiation of the 
extended sequence number (ESN) option. 


The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in RFC 2119 [Bra97]. 


2. IPsec Security Association Attribute 


The following SA attribute definition is used in Phase II of an 
Internet Key Exchange Protocol (IKE) negotiation. The attribute type 
is Basic (B). Encoding of this attribute is defined in the base 
ISAKMP specification [ISAKMP]. Attributes described as basic MUST 
NOT be encoded as variable. See [IKE] for further information on 
attribute encoding in the IPsec DOI. All restrictions listed in 
[IKE] also apply to the IPsec DOI and to this addendum. 


Attribute Type 
Extended (64-bit) Sequence Number A. B 

Class Values 
This class specifies that the Security Association will be using 
64-bit sequence numbers. (See [AH] and [ESP] for a description 


of extended (64-bit) sequence numbers.) 


RESERVED 0 
64-bit Sequence Number 1 
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3- 


Attribute Negotiation 


If an implementation receives a defined IPsec DOI attribute (or 
attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORT 
SHOULD be sent and the security association setup MUST be aborted. 


If an implementation receives any attribute value but the value for 
64-bit sequence numbers, the security association setup MUST be 
aborted. 


Security Considerations 


This memo pertains to the Internet Key Exchange protocol [IKE], which 
combines ISAKMP [ISAKMP] and Oakley [OAKLEY] to provide for the 
derivation of cryptographic keying material in a secure and 
authenticated manner. Specific discussion of the various security 
protocols and transforms identified in this document can be found in 
the associated base documents and in the cipher references. 


The addition of the ESN attribute does not change the underlying 
security characteristics of IKE. In using ESNs with ESP, it is 
important to employ an encryption mode that is secure when very large 
volumes of data are encrypted under a single key. Thus, for example, 
Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode 
would NOT be suitable for use with the ESN, because no more than 2%32 
blocks should be encrypted under a single DES key in that mode. 
Similarly, the integrity algorithm used with ESP or AH should be 
secure relative to the number of packets being protected. To avoid 
potential security problems imposed by algorithm limitations, the SA 
lifetime may be set to limit the volume of data protected with a 
single key, prior to reaching the 2%64 packet limit imposed by the 
ESN. 


IANA Considerations 


This document contains a "magic" number to be maintained by the IANA. 
No additional class values will be assigned for this attribute. The 
IANA has allocated an IPsec Security Attribute value for "Attribute 
Type". This value is listed under the heading "value" in the table 
in Section 2. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2005). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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